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Mi STATUS OF CA AIM<; 



Claims 1-11 and 13-29 are pending. Each of claims 1-11, 13-27 and 29 is under 
appeal. Pending claim 28 has been allowed. 



Amendments were filed on August 31, 1999, July 24, 2001 and November 15, 
2002. The Amendments have been entered. 

Additionally, Requests for Reconsideration were filed on September 29, 2000, 
December 7, 2001, and March 25, 2003. 

A prior Appeal Brief was filed on February 12, 2001 , resulting in the withdrawal of a 
prior Final Official Action rejecting all claims. 



The present application is directed to automated processing that facilitates the 
accessing of the proper stored payee or merchant record based on received 
information, most typically the payment information provided by a payor. Access to the 
proper payee or merchant record may, for example, be necessary to ensure that 
payment is made to the proper person or entity. Hence, if the received information is 
incorrect (e.g. due to an error in the payor's inputting of the payee name, or payee 
address or payee zip code) payment could be made to the wrong payee may or not be 
made at all. 

As summarized on page 7, line 17, through page 8, line 13, in accordance with 
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the inventive, payment information (typically including payee name(s) and payee 
address(es)) and the payor account number(s) with the payee(s), is transmitted from a 
payor station. A payment processing station receives the transmitted payment 
information and account number(s) and processes the payment information (other than 
a received zip code) to identify a zip code. The payment processing station then uses 
this identified zip code to access stored payee records, typically in a database, to locate 
the payee record with the corresponding zip code (i.e. the proper payee or merchant 
record). Additional aspects of the invention are also disclosed and claimed, as will be 
summarized below. 

The invention, as recited in claim 1 (see Figures 2-4, and the preferred 
embodiment description on page 13, line 17 through page 20, line 25), a computer 
implemented method for payment remittance processing, includes establishing a 
database (e.g. database 18) including payee records (e.g. records 1-N of Figure 4), 
each payee record having a payee zip code (see page 16, lines 2-5). A payor's (e.g. 
consumer's 8) payment information (e.g. consumer's payment record), including a 
payee zip code, is received (e.g. in step 60 of Figure 3, see page 18, lines 1-13 and 18- 
21). The payment information, other than the received payee zip code is processed 
(e.g. in step 66 of Figure 3, by the processor 1 7 of RPP 3) to identify an eleven digit zip 
code (e.g. zip 82 of Figure 4) for a payee (see page 19, lines 5-17). The database (e.g. 
merchant database 18) is accessed (e.g. in step 66 of Figure 4) to locate the payee 
record (e.g. record 1-N) having the payee zip code corresponding to the identified 
eleven-digit zip code (e.g 82) (see page 19, lines 18-23). 
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As recited in claim 2, the received payment information (e.g. consumer's 
payment record) preferably includes the received payee zip code and payee name 
information (see page 18, lines 1-7). The payment information processed (e.g. in step 
66 of Figure 3) includes the payee name information (see page 19, lines 6-17). 

According to claim 3, the received payment information (e.g. consumer's 
payment record) preferably includes a payee city and a payee state (see page 18, lines 
4-7). The payment information processed (e.g. in step 66 of Figure 3) includes the 
payee city and the payee state (see page 19, lines 6-17). 

As recited in claim 4, each payee record (e.g. record 1-N of Figure 4) has a 
payee name (see page 16, lines 2-5). The received payment information (e.g. 
consumer's payment record) includes a payee name (e.g. as described on page 18, 
lines 4-7). The database (e.g. merchant database 18) is accessed (e.g. in step 66 of 
Figure 3) to locate the payee record (e.g. record 1-N of Figure 4) having the payee 
name and the zip code corresponding to only a portion of the received payee name and 
the identified eleven digit zip code (e.g. in step 67 of Figure 4, see page 20, lines 1-19). 

According to claim 5, preferably the payee record (e.g. record 1-N of Figure 4) is 
located by matching (e.g. in step 67 of Figure 4) the identified eleven digit zip code (e.g. 
zip code 82 of Figure 4) with the payee record zip code in the database (e.g. merchant 
database 18), and matching the portion of the received payee name (e.g. the merchant 
name in the consumer's payment record) with a portion of the payee record (e.g. record 
1-N of Figure 4) payee name in the database (e.g. merchant database 18) (see page 
20, lines 1-19). 
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As recited in claim 6, typically a payment (e.g. as described on page 15, lines 2- 
24 and page 20, lines 20-21) is made (e.g. in step 64 of Figure 4 by merchant payment 
component 24) to the payee after locating (e.g. in step 67 of Figure 4) the payee record 
(e.g. record 1-N of Figure 4). 

According to claim 7, the payment may be an electronic payment (e.g. as 
described on page 15, lines 2-24). 

As recited in claim 8 and with reference to Figure 6 and page 23, line 1 , through 
page 25, line 19, the received payment information (e.g. consumer's payment record) 
preferably includes a payor account number with the payee (e.g. as described on page 
23, lines 2-4), the database (e.g. merchant database 18) includes different alteration 
rules corresponding to different payees (e.g. alteration rules 44 of Figure 6) for altering 
the account number (e.g. as described on page 24, line 19, through page 25, line 19) 
and validation rules (e.g. validation templates 40 of Figure 6) corresponding to payee 
values for fields of the account number for validating the account number (e.g. as 
described on page 23, line 14, through page 24, line 18. In this regard, account 
number conformance to the validation rules (e.g. validation templates 40) is verified 
(e.g. in step 42 of Figure 6 by the RPP 3, as described on page 24, lines 9-18). The 
verified account number is transformed (e.g. in step 46 of Figure 6 by the RPP 3, as 
described on page 25, lines 6-19) into an altered account number according to the 
alteration rules corresponding to the applicable payee (e.g. alteration rules 44 of Figure 



According to claim 9 and with reference to Figure 5 and page 21, line 1, through 
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page 22, line 25, the payee has a plurality of remittance centers (e.g. as described on 
21, lines 11-14). The account number is processed (e.g. in steps 53 and 55 of Figure 5 
by the RPP 3, as described on page 21, line 14, through page 22, line 17), to identify 
one of the plurality of remittance centers to which payment is to be remitted. The 
payment and the altered account number are then directed to the identified remittance 
center (e.g. in step 58 by the RPP 3, as described on page 21, lines 17-19). 

According to other aspects of the invention as recited in claim 10 (see e.g. 
Figures 2-4, and the preferred embodiment description on page 13, line 17 through 
page 20, line 25), a computer implemented process for locating a merchant record 
includes receiving name, street address, city and state information associated with a 
merchant (e.g. consumer's payment record as described on page 18, lines 4-7). The 
name, city and state information is processed (e.g. in step 66 of Figure 3 by the 
processor 17 of RPP 3 and as describe on page 19, lines 5-17) to identify an eleven 
digit zip code (e.g. zip 82 of Figure 4). A database of merchant records (e.g. merchant 
database 18) is accessed (e.g. in step 66 of Figure 4 and described on page 19, lines 
18-23) to locate a merchant record (e.g. record 1-N in Figure 4) for the merchant 
corresponding to the eleven digit zip code (e.g zip code 82). 

According to other aspects of the invention and as recited in claim 11 (see e.g. 
Figures 2-4, and the preferred embodiment description on page 13, line 17 through 
page 20, line 25), an automated processing system (e.g. RPP 3), includes a storage 
device (e.g. merchant database 18) configured to store payee records (e.g. records 1-N 
in Figure 4). Each payee record (e.g. record 1-N in Figure 4) has an associated one of 
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a plurality of payee zip codes (e.g. as described on page 16, lines 2-5). A data input 
unit (e.g. batch file processing unit 7) is configured to receive a payor's payment 
information (e.g. consumer's payment record), including a zip code of a payee (e.g. as 
described page 14, lines 16-24. and page 18, lines 1-7). A processor (e.g. RPP 
processor 17) is configured to process (e.g. in step 66 of Figure 3 by the processor 17 
of RPP 3, as described on page 19, line 5, through page 20, line 13) the payment 
information (e.g. consumer's payment record), excluding the received payee zip code, 
to produce an eleven-digit zip code (e.g. zip code 82) for the payee, and to retrieve one 
or more of the plurality of payee records (e.g. records 1-N in Figure 4) having the 
associated zip code corresponding to the eleven-digit zip code (e.g. zip code 82) from 
the storage device (e.g. merchant database 18). 

As recited in claim 13, the processor (e.g. in step 64 of Figure 3 by the processor 
17 of RPP 3 and described on page 15, lines 2-24 and page 20, lines 20-21) is further 
configured to direct a payment to the payee in accordance with the retrieved payee 
record (e.g. record 1-N in Figure 4). 

According to claim 14 and with reference to Figure 6 and page 23, line 1 , through 
page 25, line 19), the payment information (e.g. consumer's payment record) typically 
includes a payor account number with the payee (e.g. as described on page 23, lines 2- 
4). The storage device (e.g. merchant database 18) is further configured to store 
validation rules (e.g. validation templates 40 of Figure 6) corresponding to payee values 
for fields of the account number (e.g. as described on page 23, line 14, through page 
24, line 18) and alteration rules (e.g. alteration rules 44 of Figure 6), associated with the 
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payee (e.g. as described on page 24, line 19, through page 25, line 19). The processor 
(e.g. processor 17 of RPP 3) is preferably further configured to process the payment 
information (e.g. consumer's payment record) to verify (e.g. in step 42 of Figure 6, as 
described on page 24, lines 9-18) that the payor account number conforms to the 
validation rules (e.g. validation templates 40 of Figure 6) associated with the payee and 
to alter (e.g. in step 46 of Figure 6 as described on page 25, lines 6-19) the payor 
account number according to the alteration rules (e.g. alteration rules 44 of Figure 6) 
associated with the payee. 

According to claim 1 5 and with reference to Figure 5 and page 21 , line 1 , through 
page 22, line 25, the payee may have a plurality of remittance centers (e.g. as 
described on 21, lines 11-14). The processor (e.g. processor 17 of RPP 3) is preferably 
further configured to process (e.g. in steps 53 and 55 of Figure 5 by the RPP 3, as 
described on page 21, line 14, through page 22, line 17) the payor account number to 
identify a single remittance center of the plurality of remittance centers to which 
payment is to be directed and to direct payment (e.g. in step 58 as described on page 
21, lines 17-19) to the single remittance center. 

According to still other aspects of the system recited in claim 29, the processor 
(e.g. RPP processor 17) is further configured to process (e.g. in step 66 of Figure 3 by 
the processor 17 of RPP 3, as described on page 19, line 5, through page 20, line 13) 
the payment information (e.g. consumer's payment record), excluding the received 
payee zip code but including the payee name, to produce an eleven-digit zip code (e.g. 
zip code 82) for the payee. 
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Claims 16-21 are directed to a software implementation of the present invention. 
As, for example, shown in Figure 2 and described on page 13, lines 17-20, the 
functions of the RPP 3 can be implemented using programmed instructions stored on 
the memory 16, which are executed by the processor 17, and is not further discussed in 
this section of the brief to avoid unnecessary redundancy. 

Claims 22-27 are directed to a system embodiment of the present invention. As, 
for example, described in Figure 1 and on page 12, line 18, through page 13, line 4, 
and page 14, lines 3-4 and 16-21, a first station, such as consumer station 8, is coupled 
to a network, such as network 1, and configured to generate payment information, such 
as the consumer's payment record. A database, such as merchant database 18, stores 
the payee records, such as records 1-N in Figure 4. A second station, such as the the 
RPP station 3, is coupled to the network (e.g. the network 1), and configured to receive 
the payment information (e.g. consumer's payment record) from the first station e.g. the 
consumer station 8) via the network (e.g. the network 1), and process the payment 
information (e.g. consumer's payment record). The claimed system is not further 
discussed in this section of the brief to avoid unnecessary redundancy. 



Whether claims 1-5, 10, 11, 14, 16-20 and 29 are anticipated, under 35 USC 
§1 02(e) by Haimowitz et al. (U.S. Patent No. 5,819,291). 

Whether claim 8 is obvious, under 35 USC §1 03(a), over Haimowitz. 

Whether claims 6, 7, 9, 13, 15 and 21-27 are obvious under 35 USC §1 03(a), 
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over Landry (U.S. Patent No. 5,649,1 17), in view of Haimowitz. 



VH RRIFF DF RHRIPTinM OF THF RFFFRFMrF.q 



1 ) Haimnwify At al (N CS Patent Mn .S,«1ft,2Q1) 

Haimowitz discloses a technique for first validating and normalizing received 
data, and then using this data to enter an existing database to determine if existing data 
matches the newly received data. 

As described in column 3, lines 10-13 and 30-34, and column 4, lines 20-24, 
after being validated, Haimowitz normalizes all of the validated received data using 
common normalization rules. Hence, the described normalization rules do not 
correspond to any particular entity, but instead are common to all entities (to the extent 
there are multiple entities). 

As described in column 3 lines 63-67 and column 4, lines 11-17 and 37-59, the 
validation processing includes a validation of a zipcode against the zipcode table from 
the U.S. Postal Office. A validated zip code is normalized and utilized in a generated 
"hash key", which is in turn used for matching and thereby locating a database record 
(column 4, line 60, through column 5, line 8; see also the "hash keys" shown in column 
5, lines 52 and 61). 

As disclosed, if a received zip code is validated, it is utilized in a generated "hash 

key". 

If a received zipcode is deemed to be invalid (e.g. the city and state do not 
match the zipcode in the zipcode table from the U.S. Postal Office), the data in the field 
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is bad. Accordingly, the received record containing the non-valid zipcode is removed 
from consideration and placed in the pending file 22 (column 4, lines 37-39). More 
particularly, Haimowitz explicitly discloses that if part of the postal code (zipcode) 
cannot be used as a "hash key" (for example, if a received zipcode were determined to 
be invalid), then the data is deemed to be bad and placed in a bad data file for future 
resolution (column 4, lines 41-45). 

If a city and state, but no zip code, is received, the zip code is dubbed or derived, 
if possible, using a received city and state, and the zip code table from the U.S. Postal 
Office. That is, Haimowitz explicitly discloses that a zip code will be dubbed or derived 
from the U.S. Postal Office zip code table if a city and state, without a zip code, are 
included in the received record (column 4, lines 12-14). That is, only the city and state 
are used to derive the zip code from the U.S. Postal Office zip code table. No "building 
number" is used to derive the zipcode. Additionally, the zipcode is generated without 
utilizing a name (column 4, lines 12-13). Therefore, it is impossible for Haimowitz to 
derive an "eleven digit zipcode" because (see detailed in the discussion of the U.S. 
Postal Service's development of the zipcode in the Official Action of August 16, 2002, at 
page 7, lines 14-20, and at page 7, line 24, thru page 8, line 9). 

As described in column 5, lines 43-67, no "building number" is used to generate 
the "hash kef. 

Therefore, neither Haimowitz's derived zipcode nor generated "hash key" 
corresponds to the "eleven digit zipcode" recited in each of the independent claims. 

In summary, Haimowitz recognizes the problem of a received zip code being 
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incorrect. According to Haimowitz, if a zipcode included in the received data can be 
verified, it will be and utilized in the matching process. If a received zip code cannot be 
verified, the received data is not processed for matching, but is instead removed to a 
pending file for later resolution, since (presumably) Haimowitz does not know whether 
received city and state information or the received zip code is incorrect. Finally, if a city 
and state are included in the received data without a zip code, a zip code (although not 
an eleven digit zip code) is derived based on the postal service zip code table, and 
utilized for matching. 

2,) Landry (U.S. Patftnt No. 5,649,117) 

Landry discloses a bill payment system with payor and/or payee controls. As 
disclosed in column 6, lines 32-54, and in the portion of the section of the disclosure 
entitled "ADD A CHILD PAYEE RECORD" in column 21, a payor can establish a Child- 
Payee Record within the Payor's Record. When adding a Child-Payee Record pursuant 
to a request of the Payor, the system will check its stored Payee File to ensure that a 
Payee Record exist for the applicable Payee designated within the Child-Payee Record. 



In the Final Official Action dated January 28, 2003, claims 1-5, 10, 11, 14, 16-20 
and 29 stand rejected under 35 USC §1 02(e), as anticipated by Haimowitz et al. (U.S. 
Patent No. 5,819,291); claim 8 stands rejected under 35 USC §1 03(a), as obvious over 
Haimowitz; and claims 6, 7, 9, 13, 15 and 21-27 stand rejected under 35 USC §1 03(a), 
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as obvious over Landry (U.S. Patent No. 5,649,1 17), in view of Haimowitz. 



IX fiRnUPI MfiOFni AIMS 



The claims are in ciaim grouping of (i) independent claim 1 and it dependent 
claims 2-9, (ii) independent claim 10, (iii) independent claim 11 and it dependent claims 
13-15 and 29, (iv) independent claim 16 and it dependent claims 17-21, (v) independent 
claim 22 and it dependent claims 23-27. However, the claims of the respective 
groupings do not stand or fall together. Each of claims 1, 2, 8, 9, 10, 11, 14, 15, 16, 17, 
20, 21, 22, 23, 24, 25 and 29 recite features which form an independent basis for 
allowance. Accordingly, claims 1 and 3-7 stand and fall together, claim 2 stands and 
falls alone, claim 8 stands and falls alone, claim 9 stands and falls alone, claim 10 
stands and falls alone, claims 11 and 13 stand and fall together, claim 14 stands and 
falls alone, claim 15 stands and falls alone, claim 16 stands and falls alone, claims 17- 
19 stand and fall together, claim 20 stands and falls alone, claim 21 stands and falls 
alone, claims 22 and 26-27 stand and fall together, claim 23 stands and falls alone, 
claim 24 stands and falls alone, claim 25 stands and falls alone, and claim 29 stands 
and falls alone. 



Appellants respectfully traverse the rejections based on the prior art applied 
against the claims now pending and under appeal. As discussed below in detail, it is 
respectfully submitted that the Examiner has not met the burden of proof in establishing 
that the appealed claims are anticipated or obvious. It is additionally respectfully 
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submitted that the final rejection lacks the requisite supporting factual basis and/or 
reasonable rationale, and accordingly cannot be understood. Further still, it is 
respectfully submitted that the art applied in rejecting the claims neither teaches nor 
suggests the claimed Invention. It is also respectfully submitted that recited limitations 
have been ignored and that the relied upon art has been construed in a manner 
inconsistent with its own teachings and that the rejection is at best based on an 
improper hindsight reconstruction of the claimed invention. 

1 ■ THE EXAMINER HAS FAILED TO ESTA B I kS H A P R IMA F A CIE CA S E 

The initial burden of establishing a basis for denying patentability to a claimed^ 
invention rests upon the examiner. In r^ Finp ^ 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 
1988); In re T horpe, 777 F.2d 695, 227 USPQ 964 (Fed. Cir. 1985); In Piafifinkl ^ 745 
F.2d 1468, 223 USPQ 785 (Fed. Cir. 1984). 

The limitations required by the claims cannot be ignored. See In re Wilson , 424 
F.2d 1382, 165 USPQ 494 (CCPA 1970). All claim limitation, including t hose w hich a re 
functional, must be considered. See In re Oelrinh , 666 F.2d 578, 212 USPQ 323 (CCPA 
1981). Hence, all words in a claim must be considered in deciding the patentability of that 
claim against the prior art. Each word in a claim must be given its proper meaning, as 
construed by a person skilled in the art. Where required to determine the scope of a 
recited term, the disclosure may be used. See In r^ Rarr , 444 F.2d 588, 170 USPQ 330 
(CCPA 1971). 

The Examiner must provide sufficient factual basis or rationale as to how 
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features of the invention recited in the claims are taught or suggested in the applied art. 
Unirnyal Inn v RnHkin- Wilfiy Cnrp, 837 F.2d 1044, 5 USPQ2d 1434 (Fed. Cir. 1988). 
That is, objective evidence must be presented by the Examiner in support of the 
rejection. Without such support, the rejection is improper per se. 

It is respectfully submitted that the Examiner has failed to establish a prima facie 
case for the rejection. More particularly, the Examiner has failed to provide objective 
support or reasonable rationale for the rejections, has ignored limitations recited in the 
claims, and has applied art in a manner inconsistent with its teachings. 

Furthermore, as will be discussed further below, in the Final Official Action, the 
Examiner repeats much of the previously asserted basis for the rejection of claims over 
the prior art, as set forth in the non-final Official Action dated August 16, 2002, without 
providing a reasonable response to detailed traversal arguments, submitted in the 
remarks filed with the Amendment of November 15, 2002, highlighting those features 
and limitations which distinguish over the applied prior art (including arguments which 
specifically identify positions taken by the Examiner which cannot be reasonably 
understood and explicit requests for clarification of the Examiner's position). Instead, 
the response that is offered fails to point to any disclosure whatsoever within the 
applied art, let alone specific text or figures which might clarify the basis for the 
rejection. 

In the Final Official Action dated January 28, 2003, claims 1-5, 10, 11, 14, 16-20 
and 29 stand rejected under 35 USC §1 02(e), as anticipated by Haimowitz et al. (U.S. 
Patent No. 5,819,291); claim 8 stands rejected under 35 USC §1 03(a), as obvious over 
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Haimowitz; and claims 6, 7, 9, 13, 15 and 21-27 stand rejected under 35 USC §1 03(a), 
as obvious over Landry (U.S. Patent No. 5,649,117), in view of Haimowitz. 

Independent claim 1 requires the processing received information, other than a 
rer.eivftd paypfi zip node , to identify an eleven digit zip code for a payee. 

Independent claim 10 requires the processing a name , along with nity and state 
information, to identify an eleven digit 7ip node . 

Independent claim 11 requires a processor configured to process received 
information, excluding a received payee zip code, to produce an eleven digit zip code 
for the payee. 

Independent claim 16 requires a computer program which causes a computer to 
operate so as to process received information, excluding a received payee zip rode , to 
identify an eleven digit zip code for the payee. 

Independent claim 22 requires a second station which receives information 
including the payee name and the payee address data, and produces an eleven dig it 
zip code for the payee. 

All of the rejections rely on Haimowitz as disclosing the required 
generation/production of an "eleven digit zip code". 

On pages 3-8 (paragraphs 5-8) of the final Official Action, the Examiner 
responds to certain of the arguments traversing the prior art rejection, submitted in the 
prior response on November 15, 2002. As can be best understood, the Examiner 
acknowledges that Haimowitz discloses a process having the following multiple 
alternative processing paths: 
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1) If the received zipcode does not match the provided city and state (i.e. cannot 
be verified), then the record is set aside to pending file 22 for future resolution, and is 
not used to generate the "hash key"; 

2) If the received zipcode matches the provided city and state (i.e. is verified), 
then the received zipcode is utilized to generate the "hash key"; or 

3) If the received data includes only the city and state (i.e. does not include a zip 
code), it is used to identify or produce a 5-digit zipcode, and this zipcode is utilized to 
generate the "hash key". 

However, notwithstanding acknowledgement of the above, the Examiner, as can 
be best understood, argues that Haimowitz's generation of the "hash key" somehow 
corresponds to the identification or production of the "eleven digit zipcode" in the 
present claims. While Applicant's representative acknowledges that the "hash key" 
represents a name, city, state and zipcode, the Examiner's assertion that Haimowitz's 
"hash key" corresponds to a zipcode is not supported by the Haimowits disclosure or 
any reasonable rationale. 

The Examiner states "the rejection was based on the fact that Haimowitz took 
the customer's data (name, address, city, state, zipcode) to generate a record ID (i.e., 
hash code) to access already existing records in the database. This is no different 
[than] the lookup methodology recited by the present application with the exception that 
the record ID is an 11-digit zipcode. However, as explained in the rejection, the hash 
code of Haimowitz is no different in substance than an 1 1 -digit zipcode since they both 
contain the same type of information, (e.g., 5-digit zipcode plus delivery sector plus 
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building number) and generated in the manner recited. Applicant is reminded that there 
is no recitation in the claims directed to "looking up" the 11 -digit zipcode based on the 
"other information"... Rather, the claims recite that the 11 -digit zipcode (i.e., record ID) is 
"identified" or "produced" using information other than the provided zipcode." 

The Examiner's argument is circular and ignores explicit claim limitations. One 
can only ask how a "hash key" that is explicitly disclosed to be generated from a 
received or a separately generated "zipcode" and does not include a street address can 
be the same as the required "eleven digit zipcode". 

The Examiner asserts that Haimowitz is acting as his/her own lexicographer in 
characterizing an "1 1 -digit zipcode" as "hash code". Here again, the Examiner's logic is 
not understood. Haimowitz never even mentions an "1 1 -digit zipcode". 

An "11-digit zipcode" is a term of art and has a concise definition. Indeed, the 
Examiner has relied upon the concise definition of an "11-digit zipcode" in other 
asserted positions (see paragraphs 9 and 10 of the non-final Official Action of August 
16, 2002). Hence, the Examiner takes contradictory positions with respect to the 
meaning of an "1 1 -digit zipcode". 

Furthermore, even if the "hash key" described by Haimowitz could be considered 
to correspond to an "1 1 -digit zipcode" (which it is respectfully submitted is not the case), 
it is never identified or produced based upon received information, excluding a received 
zipcode. More particularly, Haimowitz discloses a process having multiple alternative 
processing paths. The disclosed paths are as follows: 



IF A ZIPCnnF 15^ RFCFIVPn 
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1) If the received zipcode does not match the provided city and state (i.e. cannot 
be verified), then the record is set aside to pending file 22 for future resolution, and is 
not used to generate the "hash key"; or 

2) If the provided zipcode matches the provided city and state (i.e. is verified), 
then the received zipcode is utilized to generate the "hash key". 

IF NO 7IPmnF \Si RFCFIVFn 

3) If no zipcode is received, only the received city and state is used to identify or 
produce a 5-digit zipcode, and this zipcode is utilized to generate the "hash key". 

Thus, the "hash key" described by Haimowitz is generated by using either the 
received zipcode, if it can be verified, or a derived 5-digit zipcode that has been 
identified or produced using received information which did not include a zipcode. 
Hence, the Examiner has either ignored Haimowitz's explicit disclosure of how to 
generate the "hash key", or the express limitations of the present claims. In either case, 
the Examiner fails to establish a prima facie basis for the rejection, because the 
rejection is not supported by that which is disclosed in the applied art or any other 
reasonable rationale. 

The Examiner asserts that the "hash code" described by Haimowitz corresponds 
to an 11 -digit zipcode, and as can be best understood, seems to base this conclusion 
on the fact that the "hash code" includes a name, city and state. 

However, Haimowitz is incapable of identifying or producing an 11 -digit zipcode. 
That is, according to Haimowitz, if the received record includes only a city and state 
(i.e., there is no received zip code) a zip code will be derived using the U.S. Postal 
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Office zip code table. Since Haimowitz explicitly discloses that only the city and state 
are used to derive a zip code, it would be impossible for Haimowitz to derive an eleven 
digit zip using the disclosed technique. Indeed, the Examiner's own detailed discussion 
of the U.S. Postal Service's derivation of zip codes (see Official Action dated August 16, 
2002, page 7, lines 14-20, and page 7, line 24, through page 8, line 9), leads to 
precisely this conclusion. 

More particularly, on page 7 of the non-final Official Action of August 16, 2002, 
the Examiner acknowledges that an "11 -digit zipcode" must include two digits of the 
street address. As noted above, Haimowitz explicitly discloses that only the city and 
state are used to derive a zipcode. Therefore, the two digits of the street address are 
undoubtedly missing from the information used by Haimowitz to derive a zip code, and 
accordingly, the Haimowitz derived zip code cannot be an "1 1 -digit zipcode". 

In the last sentence of the paragraph bridging pages 5 and 6 of the final Official 
Action of January 28, 2003, the Examiner asserts that Haimowitz's "hash code" is the 
same as an "11 -digit zipcode" because they both contain the same information 
including a "building number". Yet, in the same paragraph the Examiner acknowledges 
that Haimowitz's "hash code" is generated using only a name, city, state and zipcode 
(i.e. no street address or building number). 

Furthermore, in the quoted text bridging pages 12 and 13 of the final Official 
Action, which sets forth the basis for the anticipation rejection over Haimowitz, the 
Examiner explicitly cites text from Haimowitz's disclosure which confirms that m 
"building number" is used to generate the "hash code". 
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In summary, Haimowitz explicitly discloses utilizing only city and state 
information to derive a zip code, and the name, city and state to generate the "hash 
key". Thus, contrary to the Examiner's assertions, neither the derived zipcode or 
generated "hash key" can possibly correspond to the required "1 1 -digit zipcode". 

Hence, the Examiner's asserted position is inconsistent with the applied art's 
own teachings, since neither the zipcode nor the "hash key", as expressly described by 
Haimowitz, includes a building number or equivalent information, which the Examiner 
has acknowledged to be required for correspondence to an "1 1 -digit zipcode". 

There are also other inconsistencies in the positions being asserted by the 
Examiner. 

For example, with respect to claims 1,11 and 16, the Examiner contends that 
because there is no recited effectuating of a payment, the requirement that the records 
relate to a paypR is given no patentable weight. 

However, claims 1,11 and 1 6 recite that the received data is either a payor's 
payment information (see claims 1 and 11) or is received from a payor (see claim 16). 
The limitation that a paye^p record must be located based upon information of or 
received from an entirely different entity (i.e. a payor) is an express limitation of these 
claims, and relates directly to the locating of a payee record, as recited in the preamble 
of each of these claims. Hence, the limitation must be given patentable weight with 
respect to the claimed process or system, and the Examiner has not cited any basis 
supportin a contrary conclusion. 

The Examiner also states, on page 12 of the Official Action, that Haimowitz 
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generates a zipcode from address information if the zipcode is missing or innnrrf^nt . 
(emphasis added) 

However, as noted above, the Examiner has not identified any disclosure within 
Haimowitz describing the generation of a zipcode from received address information, let 
alone received address information having an incorrect zipcode. Rather, contrary to the 
Examiner's assertion, Haimowitz explicitly discloses that received information having an 
incorrect zipcode is simply set aside for later resolution. Indeed Haimowitz even 
includes a special area for storage of such incorrect address information. Furthermore, 
where zipcodes are derived, they are derived using only the received city and state 
information, not address information. 

Here again, the Examiner appears to acknowledge, in another assertion, that 
Haimowitz does not utilize incorrect received information (see page 5 of the final Official 
Action). Thus, hereto the Examiner takes inconsistent positions as to what is and is not 
disclosed by Haimowitz. At best, the Examiner seems to pick and choose those 
portions of the Haimowitz which support the conclusion which the Examiner wishes to 
reach while ignoring other portions of the Haimowitz which contradict the Examiner's 
position. 

In the sentence bridging pages 4 and 5 of the final Official Action, the Examiner 
asserts that "applicant's main argument is that Haimowitz does not "identify" (claims 1- 
10, 16) or "produce" (claims 11, 20) and 11 -digit zipcode by processing information 
other than the zipcode provided by the payee", (emphasis added) 



However, this is incorrect. 
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First, it should be understood that to the extent the claims recite that an entity 
provides a "zipcode" which is not utilized, that entity is the payor not the payee. 

Additionally, as noted above, it is acknowledged by Applicant's representative 



1) if a vftrifiahlf^ 7ipnndfi i<; rpr.pivpd^ Haimowitz uses the received, verified 
zipcode to generate the "hash key", which the Examiner (it is respectfully submitted 
incorrectly) asserts is effectively the same as an "11 -digit zipcode". NOTE: IN THIS 
CASE, HAIMOWITZ USES THE RECEIVED ZIPCODE, AND NO ZIPCODE IS 
DERIVED. 

2) if nn 7ipnnde whatsofivftr ii=; received , Haimowitz derives a zipcode (i.e. 5 digit 
zip code using only the received city and state), and uses the derived zipcode to 
generate the "hash key" which the Examiner (it is again respectfully submitted 
incorrectly) asserts is effectively the same as an "11 -digit zipcode". NOTE: IN THIS 
CASE, HAIMOWITZ DOES NOT RECEIVE A ZIPCODE AND THEREFORE DOES 
NOT DERIVE A ZIPCODE FROM RFCE IVED INFORMATION EXCLUDING A 
RECEIVED ZIP C QD FO R AN 1 1 -DIGIT ZIP C ODE. 

However, if a non-verifiable zipcode is received, Haimowitz does not use the 
received, non-verifiable zipcode, or derive a zipcode which is used, to generate the 
"hash key". Rather, the received information is set aside for later resolution. NOTE: IN 
THIS CASE, HAIMOWITZ RECEIVES A ZIPCODE, BUT DOES NOT DERIVE A 
ZIPCODE FROM RECFIVFn INFORMATION FXCI [jniNfi A RFCFIVFn JIPCnPF 

In summary, one is only left to wonder on what basis the Examiner contends that 



that: 
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one skilled in the art would consider either Haimowitz's "hash key" or Haimowitz's 
"zipcode" to correspond to the "11 -digit zipcode" required by each of the independent 
claims, when such a conclusion is inconsistent with the applied prior art's own 
teachings. 

Turning now to the dependent claims, some of the prior traversal arguments 
relating to these features are also addressed in paragraph 8 of the final Official Action. 

In this regard, the Examiner asserts that Haimowitz's "normalization" is 
equivalent to the alteration required, for example, in claim 8 of the present application, 
because "the data is reformatted into a designated standardized format" and that the 
standardized format is "based on the entity to which the data is associated (i.e., which 
the database must be searched for the existing record), such as a general business 
database or hospital database". The Examiner's rationale is not understood. 

Claim 8 requires only one database having payee records, with each record 
having a payee zipcode. Claim 8 further requires that this same database include 
respective different alteration rules, corresponding to different payees associated with 
the payee records in the single database. Hence, one can only ask what the relevance 
of multiple different databases is to the recited limitations of claim 8. A similar question 
can be raised with respect to claims 14, 20, and 23. 

Claim 9 requires that an account number be processed to identify one of a 
plurality of remittance centers to which payment is to be remitted. Claims 15, 21 and 24 
contain a similar limitation. 

As is well understood in the art, remittance centers receive remittance advice. 
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Financial institutions ultimately receive payments for deposit. Remittance centers may 
also receive payments which are ultimately forwarded to financial institutions for 
deposit. 

Landry lacks any suggestion whatsoever of the selection of one of multiple 
remittance centers for a particular payee. Even accepting the fact that merchants may 
historically have had multiple bank accounts, as asserted by the Examiner, Landry 
lacks any disclosure whatsoever of the required selection based on a received payor 
account number with a payee or directing an altered account number to a selected 
remittance center. 

Although the Examiner asserts that "construing the remittance centers as recited 
to the financial institutes is not an unreasonable claim construction", the Examiner 
provides no support for this bald statement. 

Presumably, the Examiner has failed to review the specification prior to 
construing the claims, as required under the MPEP. If such a review had been 
performed, the Examiner would clearly understand that such a construction would be 
inconsistent with the present specification, as well as the understanding of those skilled 
in the art. 

The Examiner asserts that "all electronic or physical payments are routed to the 
appropriate financial institution designated by the payee. Examiner^s Official Notice 
was based on this fact and therefore it would have been obvious to one with ordinary 
skill in the art to route the payments to the correct financial institute for payment". 

Indeed, these assertions are tantamount to an acknowledgement that the 
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Examiner's rationale does not support the asserted conclusion. More particularly, 
accepting, for purposes of argument, the Examiner's Official Notice (i.e. that all 
electronic or physical payments are routed to the appropriate financial institute 
designated by the payee), there would be no need to identify one of a plurality of 
remittance centers based on a received based on a received payor account number 
with the payee. Since the payee would have already pre-designated the proper 
remittance center. However, contrary to the Examiner's Official Notice, a payee may 
designate multiple remittance centers. Therefore a service provider must determine 
which of these multiple remittance centers a remittance (remittance advice and/or 
payment) is to be remitted to. Hence, the present invention provides the functionality 
necessary to make this selection. This, in turn, allows the single service provider to 
make payments on behalf of multiple payors whose remittance must go to different 
remittance centers of the same payee. 

Accordingly, it is respectfully submitted that the Examiner has failed to establish a 
prima facie basis for the rejection. 

9 THF APPLIFn RFFFRFNCF FAII S TO TFACH THF CI AIMFH INVFNTinN 

Anticipation, under 35 U.S.C. § 102, requires that each element of the claim in 
issue be found, either expressly described or under principles of inherency, in a single 
prior art reference. Although anticipation requires that only that the claim under attack 
"read on" something disclosed in the reference, all limitations of the claim must be found 
in the reference, or "fully met" by it. See Kalman v KlmhPriy-niark Cnrp , 713 F.2d 760, 
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218 USPQ 781 (Fed. Cir. 1983). 

A rejection under 35 U.S.C. §102 requires the disclosure in a single reference of 
each element of a claimed invention. Minnfisnta Mining A Manufacturing Cn v Jnhn<;nn 
«t Johnson Orthopaedios Inc., 976 F.2d 1559, 24 USPQ2d 1321 (Fed. Cir. 1992). 
Moreover, in rejecting a claim under 35 U.S.C, §102, the Examiner is required to identify 
where in an applied reference each feature of a claimed invention is disclosed. In re 
Rijckaert, 9 F.3d 1531, 28 USPQ2d 1955 (Fed. Cir. 1993); LIndemann Ma^nhinfinfahrik 
GMBH v. American Hoist fit Demck Co., 730 F.2d 1452, 221 USPQ 481 (Fed. Cir. 1984). 

In the Final Official Action dated January 28, 2003, claims 1-5, 10, 11, 14, 16-20 
and 29 stand rejected under 35 USC §1 02(e), as anticipated by Haimowitz et al. (U.S. 
Patent No. 5,819,291). 

As has been discussed above in connection with the failure to establish a prima 
facie basis for the rejection, Haimowitz lacks any teaching, or for that matter 
suggestion, that a received zip code which cannot be validated should or could be 
derived. Rather, if a received zip code cannot be validated, Haimowitz explicitly teaches 
that the received record is removed from consideration and placed in the pending file 
22. Thus, where Haimowitz generates a hash key from received information which 
includes a zipcode, the zipcode is used to generate the hash key. 

Haimowitz does disclose that a zip code may be dubbed or derived, but only if a 
city and state, without a zip code, are included in the received record. In such a case, 
the zipcode is derived based on the received city and state, and the U.S. Postal Office 
zip code table. As acknowledged by the Examiner, using the received city and state 
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and the U.S. Postal Office zip code table, only a 5-digit code can be derived. Hence, 
Haimowitz only generates a hash key from a derived 5-digit zipcode, if the received 
infornnation does not include a zipcode. 

Accordingly, Haimowitz never generates an 11 -digit zipcode or corresponding 
data. Haimowitz derives a zip based only on the received city and state (when no 
zipcode is received) and the hash key using the received name, city and state (but not 
the received street address, including the building number) and therefore neither the 
derived zipcode or generated hash key correspond to an 1 1 -digit zipcode. 

Nor does Haimowitz derive a zipcode or generate a hash key, using received 
information other than a received zipcode. Stated another way, Haimowitz either uses 
the received valid zipcode, along with other received information, to generate the hash 
key, or does not generate a hash key with received information which includes an 
invalid zip code. 

Therefore, it is respectfully submitted that Haimowitz lacks any teaching, or for 
that matter suggestion, of processing received information, other than a received payee 
zip code, to identify an eleven digit zip code for a payee, as required by claim 1. The 
applied reference also fails to teach or suggest processing a name, along with city and 
state information, to identify an eleven digit zip code, as required in claim 10 of the 
present application. Additionally lacking is a processor configured to process received 
information, excluding a received payee zip code, to produce an eleven digit zip code 
for the payee, as required by claim 1 1 . The applied reference also lacks a computer 
program which causes a computer to operate so as to process received information. 
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excluding a received payee zip code, to identify an eleven digit zip code for the payee, 
as required by claim 16. Finally, the applied patent lacks any teaching or suggestion of 
a second station which receives information including the payee name and the payee 
address data, and produces an eleven digit zipcode for the payee as required by 
amended claim 22. 

In summary, Haimowitz recognized the problem of a received zipcode being 
incorrect. According to Haimowitz, if a zip code is included in the received data, 
Haimowitz attempts to verify the zip code, and utilizes the received, verified zipcode to 
generate the hash key, which is in turned used in the matching process. 

However, if the received zip code cannot be verified, the received data is not 
processed for matching, but is instead removed to a pending file for later resolution, 
since (presumably) Haimowitz does not know whether received city and state 
information or the received zip code is incorrect. 

On the other hand, where a city and state are included, but a zip code is not 
included, in the received data, a zip code (although not an eleven digit zip code) is 
derived using the received city and state, and the postal service zip code table, and 
utilized for matching. 

Hence, although Haimowitz fails to recognize the benefit to be obtained by 
ignoring (rather than attempting to verify) received zip codes and by relying on the other 
received information (excluding the received zipcode) to derive an eleven digit zip code 
for matching. Furthermore, Haimowitz also fails to recognize the benefit of using an 
eleven digit zip code. 
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Thus, Haimowitz seeks to solve a similar problem to that of the present invention 
in a substantially different way, and at best teaches away from the solution described 
and claimed in the subject application (See, for example, In re Bell , 26 USPQ 2d 1529 
(Fed. Circ. 1993) and In re Marshall ^ 198 USPQ 344 (CCPA 1978). 

Other features recited in the dependent claims further and independently 
distinguish over the applied prior art. For example, claim 2 requires that the received 
payment information, which is processed to identify the eleven digit zip code for the 
payee, include payee name information. Claims 17, 25 (rejected on different grounds) 
and 29 recite similar limitations 

As discussed above, Haimowitz lacks any teaching, or for that matter suggestion 
of either identifying an eleven digit zip or utilizing a name to identify such a zip code. 
Rather, Haimowitz derives a five digit zip code using only city and state information. 
Further, Haimowitz derives a zip code only when a zip code is not received with the city 
and state information. 

Claims 14 and 20 are addressed below, in conjunction with the discussion of 
claim 8. 



3. THE APPLIED RFFFRFNCE S F AIL TO SUGGFST T HE CLAIMED INVENTION 

In rejecting claims under 35 U.S.C. 103, it is incumbent upon the Examiner to 
establish a factual basis to support the legal conclusion of obviousness. Stratoflex, Inc. v 
Aprnqijip Cnrp, 713 F.2d 1530, 218 USPQ 871 (Fed. Cir. 1983); In rP Wamfir , 379 F.2d 
1011, 154 USPQ 173 (CCPA 1967). It also is incumbent upon the Examiner to provide a 
basis in fact and/or cogent technical reasoning to support the conclusion that one having 
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ordinary skill in the art would have been motivated to combine references to arrive at a 
claimed invention, iinirnyal, In n v Riidkin- Wilfiy Cnrp 837 F.2d 1044, 5 USPQ2d 1434 
(Fed. Cir. 1988). In so doing, the Examiner is required to make the factual detemiinations 
set forth in Graham v .inhn Dfiftrfi Cn rtf Kansas City, 383 U.S. 1 , 148 USPQ 459 (1966), 
and to provide a reason why one having ordinary skill in the art would have been led to 
modify the prior art reference to an-ive at the claimed invention. Ashland Oil , Inr v Dpiita 
Rfisins A Rft frar.tnries , Inr , 776 F.2d 281, 227 USPQ 657 (Fed. Cir. 1985). Such a 
reason must stem from some teaching, suggestion or inference in the prior art as a whole 
or knowledge generally available to one having ordinary skill in the art. Uniroyal, Inc. v. 
Rudkin-Wilfty, 837 F.2d 1044, 5 USPQ2d 1434 (Fed. Cir. 1988); Ashland Oil . Inr v nelta 
Rfisins R Rftfrantnrifis, Inn . 776 F.2d 281, 227 USPQ 657 (Fed. Cir. 1985); ACS Hospital 
Systems, Inn v Mnntftfinrfi Hnspital 732 F.2d 1572, 221 USPQ 929 (Fed. Cir. 1984); In 
re Semaker, 702 F.2d 989, 217 USPQ 1 (Fed. Cir. 1983). Inherency requires certainty, 
not speculation. In re Rijckaert, 9 F.3rd 1531, 28 USPQ2d 1955 (Fed. Cir. 1993); In re 
King, 801 F.2d 1324, 231 USPQ 136 (Fed. Cir. 1986); W I finrfi A AssnniatPs, Inn v 
Garlook, Inr,., 721 F.2d 1540, 220 USPQ 303 (Fed. Cir. 1983); In re Ofiirinh , 666 F.2d 
578, 212 USPQ 323 (CCPA 1981); In re WilHinq , 535 F.2d 631, 190 USPQ 59 (CCPA 
1976). Objective evidence must be relied upon to defeat the patentability of the claimed 
invention. Fx parte Natale , 11 USPQ2d 1222 (BPAI 1988). 

In detemiining obviousness, the inquiry is not whether each element existed in the 
prior art, but whether the prior art made obvious the invention as a whole for which 
patentability is claimed. Hartness Int'l , Inn v Slmplimatln Fnq'q Co , 819 F.2d 1100, 2 
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USPQ2d 1826 (Fed. Cir. 1987). It is impermissible to pick and choose from any one 
reference only so much of it as will support a given position, to the exclusion of other 
parts necessary to the full appreciation of what such reference fairly suggests to one of 
ordinary skill in the art. in WPR<^laii ^ 353 F.2d 238, 147 USPQ 391 (CCPA 1951). 
Piecemeal reconstruction of prior art patents is improper. In m Kamm ^ 452 F.2d 1052, 
172 USPQ 298 (CCPA 1972). The Examiner must give adequate consideration to the 
particular problems and solution addressed by the claimed invention. Nnrthfim Tfilenom, 
Inn V Datapnint Cnrp . 908 F.2d 931, 15 USPQ2d 1321 (Fed. Cir. 1990); In rP 
Rnthftrmfil , 276 F.2d 393, 125 USPQ 328 (CCPA 1960). 

The fact that the prior art could be modified so as to result in the combination 
defined by the claims does not make the modification obvious unless the prior art 
suggests the desirability of the modification. In ^ DfiminRkl ^ 796 F.2d 436, 230 USPQ 
313 (Fed. Cir. 1986). The test is what the combined teachings would have suggested to 
those of ordinary skill in the art. In m Kpilpr , 642 F.2d 413, 208 USPQ 817 (CCPA 1981). 
Simplicity and hindsight are not proper criteria for resolving obviousness, In r^ Warner , 
supca. The proper approach to the issue of obviousness is whether the hypothetical 
person of ordinary skill in the art, familiar with the references, would have found it obvious 
to make a structure corresponding to what is claimed. In m Kfillftr ^ 642 F.2d 413, 208 
USPQ 871 (CCPA 1981); In re Semaker, 702 F.2d 989, 217 USPQ 1 (Fed. Cir. 1983), 
Hindsight obviousness after the invention has been made is not the test. In re Can-nil , 
601 F2d 1184, 202 USPQ 571 (CCPA 1979). The reference, viewed by itself and not in 
retrospect, must suggest doing what applicant has done. In m Shaffer , 229 F2d 476, 108 
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USPQ 326 (CCPA 1956); In m Skoll ^ 523 F2d 1392. 187 USPQ 481 (CCPA 1975). 

Again, the issue is not whether it is within the skill of the artisan to make the 
proposed modification but, rather, whether a person of ordinary skill in the art, upon 
consideration of the references, would have found it obvious to do so. The fact that the 
prior art could be modified so as to result in the combination defined by the claims would 
not have made the modification obvious unless the prior art suggests the desirability of 
the modification. See In re Gordon , 733 F.2d 900, 221 USPQ 1 125 (Fed. Cir. 1984), laie 
Deminski, 796 F.2d 436, 230 USPQ 313 (Fed. Cir. 1986), In m Kf^llpr , supra. See In re 
Laskowski, F2d., 10 USPQ2d 1397 (CAFC 1989). 

Claim 8 stands rejected under 35 USC §1 03(a), as obvious over Haimowitz; and 
claims 6, 7, 9, 13, 15 and 21-27 stand rejected under 35 USC §1 03(a), as obvious over 
Landry (U.S. Patent No. 5,649,117), in view of Haimowitz. 

According to claim 8, the verified account number is transformed into an altered 
account number according to the alteration rules corresponding to the payee. Claims 
14, 20 and 23 recite similar features. 

As noted by the Examiner, Haimowitz only normalizes data. Hence to the extent 
that Haimowitz's common normalization rules can be considered alteration rules, they 
do not correspond to any particular entity. 

Claim 9 requires that a payee have a plurality of remittance centers and that the 
received account number be processed to identify the particular one of these 
remittance centers to which payment is to be remitted. Claims 15, 21 and 24 recite 
similar features. 
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The Examiner contends that "it is notoriously old and well known in the art that 
merchants (i.e., payees, in this sense) have multiple banks that provide financial 
administrative services. Consequently systems such as Landry, which deals with 
multiple payees and payors, set up a system that will look up a specific "payee" (i.e., the 
financial institute, in this sense) to accept the payment for a payor. That is to say, it is 
irrelevant whether a "payee" (i.e., a merchant) has multiple remittance centers. Landry 
teaches that a payor's account number (i.e., record ID) is processed to determine who 
is to receive the payment (i.e., payee ID) for the merchant and directs payment to the 
identified entity." 

However, Landry lacks any disclosure whatsoever regarding the selection of one 
of multiple payment remittance centers for a particular payee, and the Examiner has not 
cited any section of Landry as disclosing such a selection. 

The relevance of the Examiner's reliance on the fact that merchants may 
historically have had multiple banks is unclear. Remittance centers receive remittance 
advice, while financial institutions ultimately receive the payments. 

Further, whether a payee has multiple remittance centers is clearly relevant in 
the context of a payment system, otherwise remittance advice may be misdirected to 
the wrong payee remittance center and hence payments are not properly accounted 
for. 

The Examiner asserts (without any support whatsoever) that Landry teaches a 
payor's account number (i.e., record ID) is processed to determine who is to receive the 
payment (i.e., payee ID) for the merchant and directs payment to the identified entity. 

34 



' Docket No.: 3350-0001 




File No.: 1158.41320X00 
Client Ref: RPP-1 

Even if this were disclosed, this would clearly suggest that Landry contemplates 
only a single payment center for each payee, and hence has not even considered the 
potential problem in making remittance to payees, let alone remittance to payees 
having multiple remittance centers (e.g. the Internal Revenue Service). 

Even if Landry had recognized such a possibility, according to the disclosed 
system, Landry's database could not associate a single payee in a database with 
multiple different remittance centers, since Landry makes no selection in the course of 
the described processing. Haimowitz also lacks any such disclosure and has not been 
applied in this regard. 

Claim 25 is addressed above, in conjunction with the discussion of claim 2. 



4. THF RFJECTION IS RASFD ON FITHFR AN IMPRnPFR HINnSIRHT 
RECONSTRUCTinN OF THF INVFNTinN RARFH ON THF APPI ICATinNR OWN 
TEACHINGS OR ON PURF SPFCIJI ATIDN 

Hindsight obviousness after the invention has been made is not the test. In 
Carroll, 601 F2d 1184, 202 USPQ 571 (CCPA 1979). The reference, viewed by itself and 
not in retrospect, must suggest doing what applicant has done. In rf^ Shaffpr ^ 229 F2d 
476, 108 USPQ 326 (CCPA 1956); In m Sknll ^ 523 F2d 1392, 187 USPQ 481 (CCPA 
1975). 

Inherency requires certainty, not speculation. In re Rijnkaftrt ^ 9 F.3rd 1531, 28 
USPQ2d 1955 (Fed. Cir. 1993); In m King , 801 F.2d 1324, 231 USPQ 136 (Fed. Cir. 
1986); W, L RorP A ARRnniate.g ^ |nr. y fiarlnr.k , Inr. . 721 F.2d 1540, 220 USPQ 303 
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(Fed. Cir. 1983); In re Qelrich, 666 F.2d 578, 212 USPQ 323 (CCPA 1981); In m Wilding 
535 F.2d 631, 190 USPQ 59 (CCPA 1976). Objective evidence must be relied upon to 
defeat the patentability of the claimed invention. Ex part^ NatalP ^ 11 USPQ2d 1222 
(BPAI 1988). 

As discussed in detail above, the appealed claims have been rejected without 
objective factual support or rational. The prior art cited in support of the rejections has 
been applied in a manner inconsistent with its own teachings. Express limitations set 
forth in the claims have been completely or effectively ignored. The evidence shows 
that there is nothing in the applied prior art to support the Examiner's position that the 
present claims are anticipated and/or obvious. Hence, at best, it can only be concluded 
that the rejection of the claims, as set out in the Final Official Action, reflects either an 
improper hindsight reconstruction of the invention based on the teachings of the subject 
application itself or pure speculation on the part of the Examiner. 



nnMHi iisinM 

It is respectfully submitted that the Examiner (i) has failed to establish a prima facie 
case for the rejection, (ii) has failed to apply art which teaches or suggests the claimed 
invention, and (ill) has, at best, attempted to improper reconstruct the invention using the 
inventors own disclosure or relied on pure speculation in rejecting the claims. Thus, the 
rejection of the pending claims as anticipated under 35 U.S.C. §1 02(e) and/or as obvious 
under 35 U.S.C. §1 03(a) over the applied prior art, whether taken individually or in any 
combination, is improper. 
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In summary, Applicants respectfully submit that the applied references do not 
teach or suggest features recited in each of the rejected independent claims, as well as 
those recited in numerous dependent claims. Accordingly, it is submitted that the art 
does not provide any teaching, or suggestion within its teachings, which would lead to the 
features or advantages of the instant invention, and the claims patentably define over the 
art. Thus, the rejection of the pending claims is in error, and reversal is clearly in order 
and is courteously solicited. 

To the extent necessary, a petition for an extension of time under 37 C.F.R. 1.136 
is hereby made. Please charge any shortage in fees due in connection with the filing of 
this paper, including extension of time fees, to Deposit Account 01-2135 and please credit 
any excess fees to such deposit account. 



Respectfully Submitted, 

ANTONELLI, TERRY, STOUT & KRAUS, LLP 



Alfred A. Stadnicki 
Registration No. 30,226 




20457 



AAS/led 
Suite 1800 

1300 North Seventeenth Street 
Arlington, VA 22209 
Telephone: (703) 236-6080 
Facsimile: (702) 312-6666 
E-mail: astadnicki@antonelli.com 
Date: June 16, 2003 
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APPFNniX O F ni AIMS UNDFR APPFAI 



1. (Twice Amended) A computer implemented method for locating a payee record, 
comprising the steps of: 

establishing a database including payee records, each payee record having a 
payee zip code; 

receiving a payor's payment information, including a payee zip code; 

processing the payment information other than the received payee zip code to 
identify an eleven digit zip code for a payee; and 

accessing the database to locate the payee record having the payee zip code 
corresponding to the identified eleven-digit zip code. 

2. (Twice Amended) The method of claim 1 , wherein: 

the received payment information includes the received payee zip code and 
payee name information; and 

the processed payment information includes the payee name information. 

3. (Amended) The method of claim 1 , wherein: 

the received payment information includes a payee city and a payee state; and 
the processed payment information includes the payee city and the payee state. 

4. (Amended) The method of claim 1 , wherein: 

each payee record has a payee name; 
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the received payment information includes a payee name; and 

the database is accessed to locate the payee record having the payee name and 

the zip code corresponding to only a portion of the received payee name and the 

identified eleven digit zip code. 

5. (Amended) The method of claim 4, further comprising the step of; 

locating the payee record by matching the identified eleven digit zip code with 
the payee record zip code in the database, and matching the portion of the received 
payee name with a portion of the payee record payee name in the database, 

6. The method of claim 1 , further comprising the step of: 

making a payment to the payee after locating the payee record. 

7. The method of claim 6, wherein: 

the payment is an electronic payment. 

8. (Twice Amended) The method of claim 1 , wherein the received payment information 
includes a payor account number with the payee, the database includes respective 
different alteration rules, corresponding to different payees associated with the payee 
records, for altering account numbers and validation rules corresponding to payee 
values for fields of the account number for validating the account number, and further 
comprising the steps of: 
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verifying that the account number conforms to the validation rules; and 
transforming the verified account number into an altered account number 
according to the alteration rules corresponding to the payee. 

9. (Amended) The method of claim 8, wherein the payee has a plurality of remittance 
centers, and further comprising: 

processing the account number to identify one of the plurality of remittance 
centers to which payment is to be remitted; and 

directing the payment and the altered account number to the identified 
remittance center. 

10. (Amended) A computer implemented process for locating a merchant record, 
comprising: 

receiving name, street address, city and state information associated with a 
merchant; 

processing the name, city and state information to identify an eleven digit zip 
code; and 

accessing a database of merchant records to locate a merchant record for the 
merchant corresponding to the eleven digit zip code. 

11. (Twice Amended) An automated processing system for retrieving a payee record, 
comprising: 
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a storage device configured to store payee records, each payee record having 
an associated one of a plurality of payee zip codes; 

a data input unit configured to receive a payor's payment information, including a 
zip code of a payee; and 

a processor configured to process the payment information, excluding the 
received payee zip code, to produce an eleven-digit zip code for the payee and to 
retrieve one or more of the plurality of payee records having the associated zip code 
corresponding to the eleven-digit zip code from the storage device. 



12. [CANCELLED] 



13. (Twice Amended) The automated system of claim 11, wherein the processor is 
further configured to direct a payment to the payee in accordance with the retrieved 
payee record. 



14. (Thrice Amended) The automated system of claim 1 1 , wherein: 

the payment information includes a payor account number with the payee; 
the storage device is further configured to store validation rules corresponding to payee 
values for fields of the account number, and alteration rules, associated with the payee; 
and 

the processor is further configured to process the payment information to verify 
that the payor account number conforms to the validation rules associated with the 
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payee and to alter the payor account number according to the alteration rules 
associated with the payee. 

15. (Twice Amended) The automated system of claim 14, wherein: 

the payee has a plurality of remittance centers; 

the processor is further configured to process the payor account number to 
identify a single remittance center of the plurality of remittance centers to which 
payment is to be directed and to direct payment to the single remittance center. 

16. (Amended) An article of manufacture for processing payment information, 
comprising: 

computer readable storage medium; and 

a computer program stored on the storage medium; 

wherein the stored computer program is configured to be readable from the 
computer readable storage medium by a computer and thereby cause the computer to 
operate so as to: 

receive payment information from a payor, including a zip code of a payee; 

process the payment information, excluding the received payee zip code, to 
identify an eleven digit zip code for the payee; and 

access a database of payee records to locate a payee record corresponding to 
the eleven-digit zip code within the database. 
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17. (Twice Amended) The article of manufacture of claim 16, wherein the received 
payment information includes the received payee zip code and payee name 
information, and the computer program is further configured to cause the computer to 
operate so as to: 

process the payee name information to identify the eleven digit zip code. 

18. (Twice Amended) The article of manufacture of claim 16, wherein the received 
payment information includes a name of the payee, and the computer program is 
further configured to cause the computer to operate so as to: 

access the database using a portion of the received payee name and the 
eleven digit zip code to locate the payee record; and 

the payee record further corresponds to the portion of the payee name. 

19. (Amended) The article of manufacture of claim 18, wherein the computer program is 
further configured to cause the computer to operate so as to: 

compare the portion of the payee name with a payee name in the payee record. 

20. (Thrice Amended) The article of manufacture of claim 16, wherein the payment 
information includes a payor account number with the payee, and the computer 
program is further configured to cause the computer to operate so as to: 

verify that the received account number conforms to validation rules 
corresponding to payee values for fields of the account number; and 
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transform the verified account number into an altered account number according 
to alteration rules of the payee. 

21. The article of manufacture of claim 20, wherein the payee has a plurality of 
remittance centers, and the computer program is further configured to cause the 
computer to: 

process the verified account number to identify a single remittance center of the 
plurality of remittance centers; and 

direct payment to the single remittance center. 

22. (Twice Amended) A system for processing payment information comprising: 



a first station, coupled to the network, configured to generate payment 
information, including a payee name, payee address data, and a payor account number 
with a payee; 

a database including payee records; and 

a second station, coupled to the network, configured to receive the payment 
information from the first station via the network, process the payment information, 
including the payee name and the payee address data, to produce an eleven digit zip 
code for the payee, access the database to locate a payee record for the payee 
corresponding to the eleven digit zip code, and direct a payment to the payee in 
accordance with the located payee record. 



a network; 
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23. (Amended) The system of claim 22, further comprising: 

alteration rules indicating a format for account numbers of the payee; 
wherein the second station transforms the received payor account number into 
an altered payor account number according to the alteration rules. 

24. (Amended) The system of claim 23, wherein the payee has a plurality of remittance 
centers and the second station is further configured to process the received account 
number to identify a single remittance center of the plurality of remittance centers, and 
to direct a payment and the altered payor account number to the single remittance 
center. 

25. (Amended) The system of claim 22, wherein: 

the processed payment information includes a portion of the payee name and a 
portion of the payee address data. 

26. (Amended) The system of claim 22, wherein: 

the second station is further configured to access the database using a portion of 
a payee name and the eleven digit zip code to locate the payee record; and 
the payee record further corresponds to the portion of the payee name. 

27. (Amended) The system of claim 26, wherein: 
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the second station is further configured to compare the portion of the payee 
name with a payee name in the payee record in the database. 



28. [ALLOWED] 



29. The automated system of claim 11, wherein the payment information includes a 
name of the payee and the processor is further configured to also process the payee 
name to produce the eleven digit zip code. 
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